Add inactivity and inclusion_delay fields to Attestation Rewards
#340
Conversation
Isn't this just going to be a constant? |
If I'm not mistaken, (Phase 0) base reward is proportional to effective balance (hence different for each effective balance increment, 32 eth, 31 eth ..etc) and it also changes over time because of Here's an example json response snippet taken from Mainnet (running Lighthouse) {
"execution_optimistic": false,
"data": {
"ideal_rewards": [
{
"effective_balance": "1000000000",
"head": "585",
"target": "586",
"source": "586",
"inclusion_delay": "534",
"inactivity": "0"
},
...
{
"effective_balance": "32000000000",
"head": "18729",
"target": "18770",
"source": "18771",
"inclusion_delay": "17083",
"inactivity": "0"
}
],
"total_rewards": [
{
"validator_index": "0",
"head": "18729",
"target": "18770",
"source": "18771",
"inclusion_delay": "17083",
"inactivity": "0"
}
]
}
} |
|
Ok that makes sense, I hadn't looked at the definitions... Looks like a good addition. Although I think some implementations (teku for example) only support from altair, the base_reward is still computed so makes sense. |
This PR adds the following fields to the
AttestationsRewardsresponse:inactivityfield to bothideal_rewardsandtotal_rewards.inclusion_delayfield toideal_rewardsinactivityCurrently the inactivity penalties are not part of the
AttestationsRewardsresponse, and is something users of this endpoint (e.g. explorers) have expressed interests in.I thought about whether it makes sense to combine them into the current
source,targetandheadfields, however I think there are a few reasons to keep them in a separate field:ideal_rewards.inclusion_delayinclusion_delayis part of the individual rewards, but not available underideal_rewards. This would be useful to indicate the idealinclusion_delayreward for each effective balance step.